home *** CD-ROM | disk | FTP | other *** search
- Date: Sat, 23 Jul 94 00:42 MET DST
- From: chris@buran.fb10.tu-berlin.de (Christian Nieber)
- To: gem-list@world.std.com
- Subject: Re: Gem List (fwd)
- Precedence: bulk
-
- Evan:
-
- > If the user clicks the mouse on a selectable and completely unobscured,
- > visible object, then why not select it instead of topping the window?
-
- My personally preferred alternative is to both top the window and select
- the item (if it's a dialog window). That's also the behaviour of dialogs in
- NeXTStep. I built this into papyrus as an option (off by default, as to not
- confuse users). Since it turned out to be annoying for document windows, it
- only applies to dialogs.
-
-
- > ========================================================================
- > And how do you see this working? The applications need to be changed as
- well,
- > or putting the forms in windows is going to do nothing more than giving
- them
- > a border. If you've got a form that can stay up whilst the rest of the
- program
- > is running then you're program has got to be able to accept events from
- it
- > at any time. There's no way the OS could do this for you.
- > ========================================================================
-
- > Nope, tops go to form window, menu bar stays, but obviously, menu select
- > messages don't take effect until after form window is closed. You can
- > top windows for other apps and run ACCs, but any top of the app that cal-
- led
- > form_do gets that form window topped.
-
- What happens if you move the dialog around, and there are windows of the
- same application behind it? Since the application that started the dialog
- is in a form_do() call, it can't react to redraw messages.
-
- Christian (R.O.M. logicware)
-